• Rebased and fixed conflicts

It should be noted that the project builds fine within MSYS2 (and the QMK MSYS bundle) so there is a small trade-off on maintainability, having to keep the 2 build systems in step.

I would be tempted to implement this more like this, swapping to cmake as to not introduce as many VS specific changes.

I personally don't like cmake for a bunch of reasons, not to mention it's an overkill for a project this size.
On Windows, it will just be a hard to use wrapper around Microsoft tools.

By looking at the comparison you linked, that one just look like a rework of another PR again - you just added the same solution I added and replaced the visual studio project files with cmake.

As long as the getopt is there, it's easy to re-create the project in visual studio. It's a plain project with all the files added.

--

I'll refrain from commenting or contributing from now on: clearly our views are different on this project and I'm not the one being paid to maintain it. Good luck.

By looking at the comparison you linked, that one just look like a rework of another PR again - you just added the same solution I added and replaced the visual studio project files with cmake.

How else would you show a comparison of an alternative solution? I locally applied your changes and went from there. I had no intentions on PRing it, and was just using the branch to better explain the changes. Such as the extra parent folder to getopt, so it doesnt dirty the unix include path, and the less error prone memset alternative. Visual studio has supported cmake projects for a while, so it doesnt seem like it adds that much overhead in the context of adding VS2019 support.